3. 컨테이너 기술과 기초 지식

3.1. 컨테이너 기술의 역사: 의외로 오래된 컨테이너 기술의 기원

3.1.1. 컨테이너 기술의 역사

최초의 컨테이너 기술은 유닉스의 chroot 명령어. 애플리케이션이 지정된 디렉터리만 접근하도록 제한하는 기능으로, 디렉터리마다 프로세스를 분리해 특정 애플리케이션의 프로세스가 다른 애플리케이션에 영향을 주지 않게 함. 이처럼 컨테이너형 가상화는 애플리케이션을 격리하는 기술이라고 할 수 있음.

이후 성장기를 지나, 지금도 대표적인 컨테이너형 가상화 소프트웨어로 불리는 도커가 2013년에 등장. 덕분에 호스트 OS형·하이퍼바이저형보다 간단하게 서버 가상화를 실현하게 됨. 하지만 대량의 컨테이너를 동시에 사용하면서 컨테이너 관리가 번거로워지는 문제가 부각됨. 이를 해결하기 위한 소프트웨어로 쿠버네티스가 개발됨. 쿠버네티스는 많은 컨테이너를 오케스트레이션(배포·관리)하는 컨테이너 오케스트레이션 도구.

컨테이너 기술의 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[chroot]          [성장기]          [Docker]          [Kubernetes]
유닉스         →  컨테이너 기술  →   2013년 등장   →   컨테이너 폭증
디렉터리 격리      발전              간단한 가상화      → 관리 자동화 필요
   │                                  │                  │
애플리케이션을      간단하게          대량 컨테이너        오케스트레이션
격리하는 기술의     서버 가상화        동시 사용 →         (배포·관리)으로
시초                실현              관리 번거로움        문제 해결

3.2. 컨테이너 기술의 장점: 가상 서버를 손쉽게 구축할 수 있다

3.2.1. 컨테이너 기술의 장점

컨테이너 기술은 가상 머신이나 게스트 OS가 필요 없음. 따라서 컨테이너를 생성하자마자 애플리케이션을 배포해 가상 서버를 구축할 수 있고, 이 간편함이 최대 장점. 도커는 주요 애플리케이션·라이브러리의 컨테이너 이미지를 모은 도커 허브를 제공해, 간단한 서버라면 명령어 하나로 가상 서버 컨테이너를 시작할 수 있음.

게스트 OS가 없다는 것은 컨테이너 내 애플리케이션도 호스트 OS의 기능(커널)을 이용해 동작한다는 뜻. 그러나 파일 시스템이 독립적이기 때문에 호스트 OS에 설치된 다른 애플리케이션·파일의 영향을 받지 않음.

컨테이너의 커널 공유 + 파일 시스템 격리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌──────────┬──────────┬──────────┐
│ 컨테이너 A │ 컨테이너 B │ 컨테이너 C │
│ 독립 파일  │ 독립 파일  │ 독립 파일  │  ← 파일 시스템은 격리
│ 시스템    │ 시스템    │ 시스템    │
└────┬─────┴────┬─────┴────┬─────┘
     └──────────┼──────────┘
                ↓
       호스트 OS의 커널 (공유)        ← 게스트 OS 없이 커널만 공유
                ↓
            하드웨어

→ 커널은 공유 → 가볍고 빠름
→ 파일 시스템은 독립 → 서로 영향 없음

3.2.2. 데이터를 컨테이너에 포함하지 않는다

컨테이너 기술에서는 가능한 한 데이터를 컨테이너에 포함하지 않는 것이 기본. 호스트 OS형·하이퍼바이저형은 애플리케이션이 기록하는 데이터가 가상 서버 안에 있어서, 가상 서버가 고장 나면 데이터도 손실될 수 있음.

컨테이너에도 데이터를 포함할 수는 있지만, 일반적으로 애플리케이션용 컨테이너와 데이터를 분리함. 데이터를 저장할 호스트 OS 디렉터리를 지정할 수 있으므로, 애플리케이션용 컨테이너를 삭제해도 데이터는 손실되지 않고 새 컨테이너에서 그 데이터를 사용할 수 있음.

애플리케이션과 데이터의 분리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[권장] 컨테이너와 데이터 분리
┌──────────────┐
│ 앱 컨테이너    │ ← 삭제·교체해도
│ (데이터 없음)  │    데이터는 안전
└──────┬───────┘
       │ 연결
       ↓
┌──────────────┐
│ 호스트 OS     │ ← 데이터는 여기에 저장
│ 디렉터리(데이터)│    (새 컨테이너에서 재사용 가능)
└──────────────┘

→ 컨테이너 삭제 ≠ 데이터 손실
→ 새 컨테이너에서 같은 데이터 사용 가능

3.3. 데브옵스와 컨테이너 기술: 개발과 운영이 원활하게 연계되도록 도와준다

3.3.1. 데브옵스란

**데브옵스(DevOps)**는 개발자(Development)와 운영자(Operations)가 협력해 서비스를 제공하는 방법. 개발자는 계획 → 코드 → 빌드 → 테스트 순으로, 운영자는 릴리즈 → 배포 → 운영 → 감시 순으로 진행하며, 감시 결과가 다시 개발 계획으로 이어짐. 담당 업무가 달라 연계가 어려운 두 역할이 협력해 서비스를 신속하게 제공하자는 것이 데브옵스의 사고방식.

데브옵스의 무한 순환:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

        [개발 (Dev)]              [운영 (Ops)]
     계획 → 코드 → 빌드 → 테스트  릴리즈 → 배포 → 운영 → 감시
       ↑                                              │
       └──────────────────────────────────────────────┘
                감시 결과를 다음 계획에 반영

→ 두 역할이 끊김 없이 연결되어 순환

3.3.2. 데브옵스와 컨테이너 기술

데브옵스를 실현하는 도구가 정해진 것은 아니지만, 개발과 운영 두 순환을 더 원활하게 돌리기 위해 컨테이너 기술을 자주 사용함. 예를 들어 개발 환경에서는 정상 작동했지만 운영 환경에서는 오류가 나는 경우가 잦은데(기계 성능 차이, 기존 서비스와의 충돌 등), 컨테이너는 애플리케이션 실행에 필요한 프로그램과 라이브러리를 하나의 패키지로 결합하므로 다른 서버로 그대로 옮겨도 작동함.

이렇게 컨테이너는 이식성(Portability)이 매우 높아 개발 환경에서 쓰던 컨테이너를 운영 환경에서도 그대로 사용할 수 있음 → 개발과 운영을 원활하게 연계.

"내 환경에선 됐는데" 문제 해결:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[기존] 환경마다 다름 → 운영에서 오류
개발 환경 ✓  →  운영 환경 ✗ (성능 차이·충돌)

[컨테이너] 패키지째 이동 → 동일하게 작동
┌────────────────────┐
│ 컨테이너            │
│ 앱 + 라이브러리 묶음 │  →  개발 ✓ = 운영 ✓
└────────────────────┘
→ 그대로 옮겨도 작동 (높은 이식성)

3.4. 주요 컨테이너 기술: 도커 이외의 다양한 컨테이너 기술

3.4.1. 도커 이외의 컨테이너 기술

컨테이너 기술은 리눅스에서 발전했기 때문에, 리눅스에는 컨테이너형 가상화를 실현하는 소프트웨어가 많음.

3.4.2. containerd와 cri-o

**컨테이너디(containerd)**는 원래 도커의 일부였지만 분리되어 공개됨. 현재 업계 표준 컨테이너 런타임이며, 도커도 내부에서는 컨테이너디를 사용함. 컨테이너 이미지 전송, 컨테이너 실행·감시, 라이프 사이클 관리 등을 담당.

**크라이오(cri-o)**는 경량 컨테이너 런타임으로, 컨테이너 관리 도구인 쿠버네티스에 특화되어 있음. 컨테이너디와 크라이오 모두 **CRI(Container Runtime Interface)**에 근거함. CRI는 쿠버네티스와 컨테이너 런타임이 통신할 때 사용하는 규정.

쿠버네티스와 컨테이너 런타임:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

        [쿠버네티스]
             │
       CRI (통신 규정)        ← 표준 인터페이스
             │
   ┌─────────┴─────────┐
   ↓                   ↓
[containerd]        [cri-o]
업계 표준 런타임      경량·쿠버네티스 특화
(도커도 내부에서 사용)

→ 두 런타임 모두 CRI 규격을 따름

3.5. 마이크로서비스: 컨테이너와 궁합이 좋은 설계 기법

3.5.1. 마이크로서비스와 모놀리스

마이크로서비스는 의존 관계가 없는 여러 작은 서비스를 조합해 큰 서비스로 제공하는 설계 기법. 반대로 하나의 큰 기능을 단일 서비스로 제공하는 설계 기법은 모놀리스. 마이크로서비스는 작은 서비스 각각을 독립적으로 가동할 수 있어 기능 파악, 장애 분리, 병렬 개발, 변경 등을 쉽게 수행함.

모놀리스 vs 마이크로서비스:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[모놀리스]                  [마이크로서비스]
┌────────────────┐        ┌────┐ ┌────┐ ┌────┐
│  하나의 큰 서비스 │        │서비스│ │서비스│ │서비스│
│  앱A·앱B·앱C가   │        │ A  │ │ B  │ │ C  │
│  한 덩어리로 결합 │        └──┬─┘ └──┬─┘ └──┬─┘
└────────────────┘           └──────┼──────┘
                                  조합 → 큰 서비스
✗ 일부 변경이 전체에 영향        ✓ 독립 가동·장애 분리
✗ 장애 분리 어려움              ✓ 병렬 개발·변경 쉬움

3.5.2. 마이크로서비스와 컨테이너

컨테이너 기술은 애플리케이션마다 컨테이너를 만들고 이들을 연결해 하나의 큰 서비스를 만들 수 있어, 마이크로서비스와 궁합이 매우 좋음. 호스트 OS형 가상화로도 마이크로서비스를 구축할 수 있지만 애플리케이션마다 환경을 따로 구축해야 함. 반면 컨테이너는 생성 비용이 매우 낮아 애플리케이션마다 컨테이너를 만드는 것이 간단.

다만 여러 서비스를 여러 컨테이너로 구축하면 상당히 복잡해지므로, 대규모 마이크로서비스에서는 컨테이너 오케스트레이션 도구(쿠버네티스 등)의 도입이 필요함.

3.6. 컨테이너와 서버리스의 비교: 서비스 개발의 두 가지 주요 흐름

3.6.1. 서버리스란

**서버리스(Serverless)**는 "서버가 없다"는 의미로, 서버가 존재하지 않는 것처럼 보이는 환경. 주로 클라우드에서 제공되며, 최소 단위는 **기능(function)**으로 사용자 요청이 있을 때만 가동되고 처리가 끝나면 종료됨. 실제로는 서버가 응답하지만 클라우드 운영자가 관리하므로 개발자가 의식할 필요가 없음. 즉 서버가 없는 것이 아니라, 개발자가 서버를 관리할 필요가 없다는 뜻.

서버리스는 SaaS와 PaaS의 중간 분류인 FaaS로 지정됨. 대표 서비스로 AWS의 Lambda가 유명.

3.6.2. 서버리스의 장단점

3.6.3. 컨테이너와 서버리스의 차이

컨테이너는 리눅스·윈도우만 있으면 실행할 수 있지만 서버리스는 주로 클라우드에서 실행됨. 또 컨테이너는 애플리케이션 단위, 서버리스는 더 작은 기능 단위로 구성됨. 그래서 서버리스는 비교적 짧은 시간 안에 처리하는 데 사용됨(예: 이미지가 업로드되면 등록한 기능이 가동되어 이미지 크기 조절·썸네일 자동 생성).

특정 클라우드에서 개발한 기능을 다른 클라우드 벤더로 옮기는 것은 난이도가 높으므로, 이식성·자유도는 컨테이너가 훨씬 높음.

핵심 요약

3장 컨테이너 기술과 기초 지식 요약:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[역사]
chroot(유닉스) → Docker(2013) → Kubernetes(오케스트레이션)
└─ 컨테이너 = 애플리케이션을 격리하는 기술

[장점]
├─ 게스트 OS 불필요 → 생성 즉시 배포 (간편)
├─ 호스트 커널 공유 + 파일 시스템 독립
└─ 데이터는 컨테이너와 분리 → 컨테이너 삭제해도 안전

[데브옵스]
├─ 개발(계획·코드·빌드·테스트) + 운영(릴리즈·배포·운영·감시)
└─ 컨테이너의 높은 이식성 → "개발=운영" 환경 일치

[주요 기술]
├─ LXC·libvirt·libcontainer·systemd-nspawn·cgroups·CRIU
└─ 런타임: containerd(업계 표준) / cri-o(쿠버네티스 특화)
   └─ 둘 다 CRI 규격 기반

[마이크로서비스]
├─ 작고 독립적인 서비스 조합 (↔ 모놀리스: 단일 덩어리)
└─ 컨테이너와 궁합 ↑ (대규모는 오케스트레이션 필요)

[컨테이너 vs 서버리스]
├─ 컨테이너 : 애플리케이션 단위 · 이식성 높음
└─ 서버리스 : 기능 단위 · 짧은 처리 · 관리 부담 ↓ (FaaS, AWS Lambda)

결론:
→ 컨테이너는 가볍고 이식성 높은 격리 기술
→ 데브옵스·마이크로서비스를 떠받치는 기반

참고 자료

관련 자료:

• Docker 공식 문서: https://docs.docker.com/
• Kubernetes 공식 문서: https://kubernetes.io/ko/docs/
• containerd: https://containerd.io/
• CRI-O: https://cri-o.io/
• CRI (Container Runtime Interface): https://kubernetes.io/docs/concepts/architecture/cri/
• LXC (Linux Containers): https://linuxcontainers.org/
• AWS Lambda(서버리스): https://aws.amazon.com/lambda/
• 마이크로서비스란 (AWS): https://aws.amazon.com/microservices/

네비게이션